Software defined networking is an emerging architecture for data transfer networks. In a software-defined network “SDN”, the control plane is separated from the data plane so that the control plane is implemented in one or more controllers that can be separate from the network elements and the data plane is implemented in the network elements. The network elements can be, for example, Internet Protocol “IP” routers, multiprotocol label switching “MPLS” nodes, packet optical switches, and/or Ethernet switches. Each network element may consist of a single apparatus or a combination of a plurality of apparatuses. Typically, the software defined networking allows for quick experimenting and optimization of switching and/or routing policies and external access to the innards of network elements that formerly were closed and proprietary.
Internet Protocol “IP” based networks were initially built based on the concept of Autonomous Systems “AS”. This concept allows networks to scale and extend by connected junctions that forward packets to a reasonable next hop based on partial need-to-know information. The AS principle works much like the traditional post office service, where a postal worker in a given city does not need to know all the tenants of all the streets in another city in order to choose a reasonable next hop for a letter at hand. This approach to networking is simple, and has proven resilient and scalable. This approach has, however, a few drawbacks. It does not allow the designated destinations, or tenants with home mail-boxes, to move without changing their identity as far as the packet delivery service is concerned. The topological location of destinations, which is the network interface they are attached to, dictates their identity related to the packet delivery service. In addition, using only the basic AS principle, it is hard to specify other qualities, such as logical grouping, access control, quality of service, intermediate network processing, or to specify aspects that relate to a sequence of packets that form a flow.
Using the analogy of the postal service, the software defined networking works, for any given street location, so that all the letters from all the tenants would first be aggregated by a network element on an edge a software-defined network. This network element is configured to examine the current location for each of the letter-destinations using a global lookup mechanism. Based on that global lookup and on other globally defined and globally measured considerations, such as access control or remote location load conditions, the said network element places one or more of the original letters in an additional envelope addressed to each of the street locations where the destinations currently are. It then uses the normal postal service which works like the traditional Internet Protocol “IP” to get these outer envelopes to the remote locations. This is done based on the existing and scalable hop-by-hop forwarding services. The outer letters are then opened by a remote network element and the original envelopes are delivered to the destinations. It is to be noted that the above-presented analogy between the software defined networking and the postal service is a strong simplification and it gives only a limited viewpoint about the versatile possibilities provided by the software defined networking.
The software defined networking is, however, not free from challenges. Some of the challenges are related to configuring the network elements so that they are capable of carrying out desired tasks. In many cases, a protocol according to the OpenFlow specification is used for communicating configuration data from the controller of a software-defined network to the network elements of the software-defined network. The OpenFlow specification is managed by the Open Networking Foundation “ONF”. A network element supporting the OpenFlow specification is adapted to maintain one of more look-up tables, i.e. one or more flow tables and a group table, which define actions to be executed when managing, e.g. forwarding or modifying, data frames. The versatility of the actions is dependent on the flexibility of a look-up table structure and on a set of pre-determined actions that can be related to the entries of the look-up tables and are executable in response to a situation in which a relevant portion of a data frame matches the relevant entry. For example, in conjunction with the OpenFlow, the need to add new actions has led to increased complexity of the OpenFlow specification and, as a corollary, to increased complexity of network elements supporting the OpenFlow specification. Therefore, there is still a need for technical solutions for configuring network elements of software-defined networks.